A standing join benchmark, and the control that makes it legible (#401) - #427

The finding is the right one and the harness is right to assert it. One hole in the

ratio guard, which is the #418 shape again.

A join does not cost us through the join. It costs us by disabling the thing we are fast
at.

That is the sentence, and the S0-against-S1 pair is what makes it a measurement rather than
a story. 0.53x with no join and 1.36x with one, same rows and same bytes, is a much more
useful result than "we lose on joins" would have been.

Asserting the mechanism instead of narrating it is the part I would keep hardest:

ok  premise: the no-join control really is vectorized
ok  premise: a join between scan and aggregate disables it
ok  premise: S1 uses the same join method in both arms (Hash Join)

That third one matters more than it looks. Without it a reader cannot tell whether the
1.36x is our scan or the planner choosing a different join for each arm.

Blocking, and it is small: the ratio guard misses a half-empty measurement

case "$h$c" in
    *ERR*|"") ;;
    *) r=$(awk -v a="$c" -v b="$h" 'BEGIN { printf "%.2f", a / b }') ;;
esac

"$h$c" is only empty when both sides are. With one side missing it concatenates to a
non-empty string, falls through, and divides. Measured:

heap=[1500] col=[800 ] -> ratio=[0.53]     correct
heap=[    ] col=[800 ] -> ratio=[inf]      <-- prints inf
heap=[1500] col=[    ] -> ratio=[0.00]     <-- prints 0.00, reads as a 100% win
heap=[ERR ] col=[800 ] -> ratio=[-]        correct
heap=[    ] col=[    ] -> ratio=[-]        correct

0.00 is the dangerous one. A columnar arm that produced no timing at all renders as the
best result in the table, in a document whose whole purpose is to be quoted.

timed() returns the empty string whenever the Time: grep misses, which is a different
path from the ERROR branch it already handles: a cancelled query, a psql connection
failure, or an output format change all land there rather than on ERR.

Test each side rather than the concatenation:

case "$h" in ''|*ERR*) r=- ;; *) case "$c" in ''|*ERR*) r=- ;; *) r=$(awk ...) ;; esac ;; esac

or reuse check_ratio from test/lib.sh, which refuses an empty side and a zero on either
side, and now has a self-test for exactly this (#422, #425).

This is the same class as the bc failure that started #418, and it is worth fixing here
because a benchmark table is the artifact most likely to be pasted somewhere without the
run log beside it.

Not blocking

The - in the ratio column and the raw ERR in the value columns are good. The value
is visible rather than suppressed, so a reader sees the gap. Keep that.

Worth stating the run conditions in the docs table itself, not only in the PR. Median
of three, interleaved arms, serial, PG18.4 non-assert: that belongs next to the numbers,
because the numbers will outlive this PR description.

Fix the guard and this has my approval. The result itself I have no argument with.

Fixed, self-tested, and better than what I asked for. One inconsistency to note.

Every case I raised is handled, verified against your helper directly:

  num=[1500] den=[800]  -> 1.88
  num=[    ] den=[800]  -> -
  num=[1500] den=[   ]  -> -
  num=[ERR ] den=[800]  -> -
  num=[800 ] den=[ERR]  -> -
  num=[800 ] den=[  0]  -> -

The self-test running before any number is printed is the part I would not have asked
for and would keep. A ratio helper that silently passes a half-empty pair is worse than
none, and this one proves itself on every run rather than being trusted.

One inconsistency, and you decide which way it goes

lib.sh's check_ratio and bench/'s ratio() now answer the same question differently:

lib.sh   check_ratio 0 800 0.5  ->  FAIL  a side of the ratio is zero, so nothing was measured
bench    ratio       0 800      ->  0.00

You closed the zero-numerator hole in check_ratio on #422 for exactly the reason that
applies here: "the thing we measured cost nothing" is nearly always "the thing we measured
did not happen". In a benchmark table a 0.00 reads as the most flattering number
possible, which is the same argument your own comment makes about it being quoted without
the run log.

Not blocking, because a genuine 0 ms timing is less reachable than a genuine 0 buffer
count: timed() extracts psql's Time: n.nnn ms, which is not 0 for a real query. But
two guards for the same job with different strictness, written the same week, will confuse
whoever reads them next. Either match them or say in the comment why bench is looser.

The TimescaleDB withdrawal

Withdrawing an arm rather than shipping one you could not stand behind is the right call
and I would rather see that than a number with a caveat attached. Nothing further from me
on it.

The finding itself I already agreed with: S0 against S1 is the measurement, and asserting
that both arms use the same join method is what makes the 1.36x attributable to our scan
rather than to the planner choosing differently.

Approving. Merge when you are ready, or after the matrix if you would rather.